Supporting both hash and keyword arguments is making this a bit complicated. I don't think we need to match the Rails enum method exactly here, since the use cases are a bit different (for example, I think passing the values to traits_for_enum as keyword arguments would be fairly uncommon, and it's also not something we've tested).

I'd rather accept a single values argument (like a hash or array), and keep the prefix and suffix keyword arguments separate. That also allows us to get rid of the ugly underscores.

So that would look like:

    def traits_for_enum(attribute_name, values = nil, prefix: false, suffix: false)
      @definition.register_enum(Enum.new(attribute_name, values, prefix: prefix, suffix: suffix))
    end

All of our tests still pass with this change (assuming we update the _prefix and _suffix keyword arguments to remove the underscores).

the issue here is not necessarily that key names are needed, but more that a third argument is needed for setting options, but the traits_for_enum allows for values to be nil (in which case the second arg passed becomes options, not values).
if traits_for_enum is invoked with values being passed in, a third arg with options works fine, but if values is not passed in, the "options" now are the second arg, meaning values (was meant to default to nil) and options (was meant to be passed in) are both jeopardised.

i can think of 2 options here,
1: the code update I've made, which looks good from an api usage point of view, but means traits_for_enum becomes messy, as it has to try to determine on the fly what the intention of the second arg is.

2: if "options" are being used, values is a key name too (eg: traits_for_enum(:foo, values: [:a, :b], prefix: true, suffix: true), which means the consumer of the api has to change their code (only when setting options, which are a new concept so all current usage continues to work) but will need to migrate over when wanting to set prefix/suffix.

also, making the change you suggested above fails the test on line 60 (because of the confusion about what teh second arg is)

Do prefix and suffixes interact differently with a hash vs. list, or is there something specific we're trying to cover by testing against both? If not, I think we could choose one or the other to test with, since we've already got coverage of the various enumerable types.

With the current form of the code, no they don't behave differently, however with hash being passed in one of the tests (enum_for_trait_spec.rb:60) was failing as the keynames of the hash didn't match with the prefix, suffix options, so i chose to leave the 2 different tests in (for now at least) to ensure i pushed a solution that worked for all implementation types of the api

Are we using this anywhere?

This was being used in lib/factory_bot/definition.rb to help with not redefining traits in the automatically_register_defined_enums method, it is now used in the Definition#register_enum method as the key in the registered_enum hash

this is now also being used in the registered_enums hash as the key to look up to ensure enums are not registered twice

Might be worth pointing out we would need to update the docs here if we end up using the signature without the hash arguments.